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Net. Debugged an internet connectivity problem. Okay, be careful now. Brought down Yahoo with
a DDoS attack. Okay, just a few of you. Here is one possible definition of NAT. I couldn't
find anything official or formal on the internet anywhere, so I'm sort of making this up. The
assigning of two different IP addresses to the same TCP IP host, a public one to be used when
accessing the host from inside the security perimeter, and a private one to be used when
accessing the host from outside the security perimeter. So as you all probably know, the basic
concept of NAT is that you establish a security perimeter around your organization and use
different IP addresses on the inside and on the outside. You need a network address translation
box, a NAT box, and a network address translation box. You need a network address translation box,
sitting on the perimeter in order to do the intelligent translations back and forth. But
this is the basic concept. If you have a better definition, I'd like to hear it, but I think this
works pretty well. Some basics. We're going to talk about RFC 1918, the concept of private IP
addresses, and two general modes of operation for NAT. You've all probably heard of by now the
Internet Hacking System. The Internet Hacking System is a very popular and very popular
engineering task force. They archive these things called RFCs. They are requests for comments. This
is the, I guess, democratic unstructured way that the Internet has developed. Somebody comes up with
a bright idea and posts publicly a request for comment. Basically what they're saying is, I think
this is a good idea. I think this is the way the world should do things. I assert this is the best
we've got.
And I'm posting this for comments. And only after it's been subjected to perhaps withering public
scrutiny do people sort of generally agree that, yeah, this works. So most of the internet, the
specifications, have been designated and cleared up and archived in these RFCs. The famous one for us,
in terms of network address translation, is 1918. Anybody who knows NAT, anybody who can tell you the
story about those funny IP addresses,
192.168? How many people here have seen a strange look, seen some addresses 192.168 and you know there's something funny about them but you're not quite sure what it is? Hands? Thank you.
So, in 1918, address allocation for private internets discusses some of this, but not all of it. You can find them all at IETF.org. There's all sorts of great stuff. On a boring, rainy afternoon, it's a terrific way to learn some more things about the internet.
Okay.
Thank you.
Okay. So let's talk about private IP addresses. On the bottom row there, you see the 192.168s. Now, early in your careers, when messing with TCP IP and routing issues, you quickly figured out that there was something different and strange and special about those IP addresses. If you were paying attention, you figured out that they couldn't route out to the internet. These are three different classes of IP addresses.
So, what's sort of interesting about this is that there's 16 million IP addresses that have been reserved and are private. One of them is a Class A block, the tens.
So, if you ever see any IP addresses starting with Ten, you know that these are private, uh... they're non-routable on the internet. We'll talk about some of these special characteristics here in a minute.
Um... this is particularly nice because you've got 16 million IP addresses, and you can use this no matter how big your organization is. You can use the Ten block to help get things structured internally.
The class B blocks, which are the toughest trivia question here, ask somebody what are the class B private address blocks, 17216 through 17231.
There are 16 class B blocks available, each of which has 64,000 IP addresses, and there are 256 class C blocks, each of which has 256 IP addresses.
So you should know, if you ever see any host with these IP addresses, that there's something special going on.
These are private IP addresses. They are non-routable on the Internet, and we'll talk about some of the special characteristics here.
These private addresses are reserved in that they'll never be assigned to someone in the global Internet routing scheme.
There is no host out there at 192168 on the Internet somewhere. None. There are none.
In fact, every router on the Internet is required to drop all packets addressed.
To any IP address in these blocks. So you don't have to worry about it.
So if you're on your corporate LAN, and you know there's a web server that you're using at 10.1.1.1, what does that say to you?
Well, the immediate conclusion you can come to is that, well, that must be internal to my corporation somewhere,
because you know for a fact it can't be over the Internet, because you can't get to it.
So it's nice that you never have to worry about a collision.
You never have to worry about, well, if I make my host 10.1.1.1, oh no, have I just screwed up my routing tables?
You know, what if there is a 10.1.1.1 out there? I'm never going to be able to reach them now,
because, you know, I'm going to be routing back to myself.
So one of the benefits of having private IP addresses is you can use them all you want internally,
and you have no fear that you're going to screw up your routing tables and find yourself colliding with something that's legitimate and valid out on the Internet,
even though, for a fact, it's not.
Packets with a private address destination are dropped by Internet routers, and we're going to talk about one of the benefits of this in the future.
If one of your internal machines that you don't want people on the Internet to have access to has one of these private IP addresses,
it's a lot harder for someone on the Internet to connect to it, because any packets that a hacker sends to 192.168,
as soon as they get out on the Internet, they're going to be dropped, right?
This is even better than an access control list. This is... I don't have an address you can get to.
Anyone can use them internally, as they'll never collide with external addresses.
Okay, we've talked about RFC 1918 and some private addresses.
If you've been playing with network address translation, you've probably seen that in most firewalls,
in particular here, the Checkpoints Firewall 1.
If you notice here, I'm sort of using some other translation.
Well, I am.
There are two modes, generally speaking, for network address translation.
Hide mode, otherwise known as many-to-one, or static mode, which is one-to-one.
And this is largely because when it comes to granting Internet access in your organization,
you can pretty much partition all of your TCP IP hosts into two groups,
those of which should have some access,
by people on the Internet, you know, your mail server, right, your web server, your FTP server,
and those that you never want anyone on the Internet to have access to,
your payroll server, the accounting server, your workstation, say.
I'm speaking only of connections coming from the Internet in, not connections going from the inside out.
So if you're like most organizations, you can partition all of your TCP IP hosts,
you know, all but five of them.
You want to be internal and protected.
For the purposes of this discussion, I'm going to call that the LAN, the local area network.
And then there's maybe four or five servers, or hundreds if you're a big content provider,
and you're going to want those to be allowed at least some access from people on the Internet.
And I'm going to call that the DMZ, demilitarized zone, which is sort of not very descriptive,
but it's a special zone, perhaps it's even a special nick off of your firewall on a protected subnet,
in which you're allowing some access.
By people on the Internet.
Very filtered, very specific, very carefully monitored access,
but you are allowing some access.
But the machines on the inside, like, you know, the woman who does payroll, her laptop, you know, her desktop machine,
you don't want people on the outside to be able to connect to that under any circumstances.
So those go in the LAN, and they'll be in something called hide mode.
Static motor one-to-one is what you typically do for servers,
machines that you wish to make available.
So the moral of the story is, if you're going to set up NAT in your organization,
one of the first things you need to do is basically think about all your TCP IP hosts
and partition them into two groups, mutually exclusive, collectively exhaustive,
and figure out which ones go in the DMZ and which ones go in the LAN.
And that'll help you figure out which mode to use.
Okay, so we've talked about the first section here.
Let's have some questions.
I've talked about RFC 1918.
I've talked about RFC 2018.
I've talked about private IP addresses.
I've talked about two modes of network address translation.
Questions?
Things I've screwed up on.
Yes?
How would NAT work in a VPN situation?
The question is, how would NAT work in a VPN situation?
The short answer is, with great difficulty.
It's a real problem.
I believe IPSec embeds the IP address of the host, and that goes out.
It's some problems.
I don't know a whole lot more than that that I can share with you at this point.
But yes, there's some real difficulties if you're trying to use a VPN with NAT.
Because NAT, the host and the server, or the two ends of the connection using NAT,
basically don't need to, and perhaps cannot, be aware of the fact that network address translation was used.
We'll show here.
I'm going to go through some descriptions here and walk through with packets.
And I'm going to show that both, for example, if you're browsing the web with a client using network address translation,
neither side is even aware that NAT is going on.
So for most protocols that operate with good manners and don't embed IP addresses in the payload,
then NAT works just fine.
But one of the security aspects of some VPN protocols is that in order to prevent various attacks, et cetera,
they embed the IP address in the payload, and that can cause some problems.
.
So the best way to do that is to have...
The best way to solve this problem is to have the VPN and your firewall working together.
For example, Checkpoint Firewall 1, the example I know.
I'm not trying to plug them.
They do that well.
You can mix the VPN with network address translation.
Other questions?
Okay.
This is a typical NAT configuration.
This is a highly stylized, simple network.
This is your new .com company.
Two years ago.
They've been in business for two weeks.
The Big Eye Internet.
We have a gateway router.
It's your Cisco 1700 or your Cisco 3600, whatever it is.
You're running a firewall there with NAT.
And you'll see that there are two separate NICs coming out of that firewall.
I'm really trying to separate those two LAN segments to the greatest degree possible.
On the lower right, we have the DMZ.
And you'll see we've got a worldwide web server.
We have a mail server and an FTP server.
And those machines are in the DMZ because we do want people on the Internet to have some limited access to those machines.
On the lower left-hand side is the LAN.
And there's the server there and various users.
And, again, the purpose is we don't want anyone on the Internet to have any access to the people in the LAN.
So we've already done this partitioning.
We've already got it split out here.
Into two separate subnets with two separate policies.
The one on the lower right is using static mode NAT.
The one on the lower left is using hide mode NAT.
Question?
What if your router is what handles the NAT?
Can you still split it up in those two different modes?
The question is what if your router does your NAT for you?
Can you still split it up into two different modes?
Like lower end Cisco routers?
675, 678, 800, stuff like that?
Okay, the question is particularly about low end Cisco routers.
I don't know.
If there's a single NIC coming out on the bottom of the router, then it makes it a lot harder, obviously, to split it into two NICs.
You know, put a switch underneath it and do the best you can.
You know, the point of security is not to be perfect.
It's just to put up, you know, as many sort of walls to climb over as you can.
One of the purposes of splitting it into two different NICs is it's like those lizards in the deserts of Arizona
who have those big tails.
And if a predator grabs the tail, well, the tail breaks off and the lizard gets away.
And the DMZ is sort of the lizard's tail here because you are allowing some access from the Internet.
There is still some chance of somebody taking over one of your servers.
And so you set up your routing rules and the firewall rules in such a way that even if somebody takes over your web server,
they still can't get into the LAN.
Okay, this is the whole reason why you use two separate subnets and have two separate policies here.
You know, obviously nobody wants to get their web server taken over.
But if it does, well, okay, you can flatten that hard drive and start over.
But at no time did they have enhanced access to get back into the LAN and get into your payroll server,
which is the real concern.
So that's the motivation behind having these two different LAN segments.
The question is that some routers will do specific port forwarding, limiting packets destined for certain ports only to certain IP addresses.
That sounds like an access control list or basic firewall configuration issues.
It's like if a packet comes in on port 80, then it goes forward to a certain address.
So it does sort of do what you would ask it to do.
.
NAT in action.
All right, we're going to – I wanted to have a little icon here of a guy named NAT,
and I was going to use him as a little animated something stupid here.
But with my lame amateur PowerPoint skills, you've been saved.
So we're going to –
.
NAT in action.
All right, we're going to look here.
There are four possibilities.
We're going to look here at hide mode and static mode.
There's another cell phone.
And we're going to look at outbound connections and inbound connections and see what happens.
Okay, the first thing we're going to do here is talk about what's inside an IP packet.
I could spend four days talking about what's inside an IP packet.
I'm just going to mention a couple of basic fundamental things that you need to know for network address translation.
You can get a Ph.D. in IP packetology, I'm sure, from somewhere.
Two of the most important things are the IP source address.
Every TCP IP packet that goes anywhere contains the source address of the machine where it came from.
Or if you spoof it, it can contain any IP address you want.
But let's start with normal expected IP packets, which have the IP address of the TCP IP host that sent the packet.
.
Another thing it also contains is the destination.
You wouldn't be able to route the packet over your network or over the Internet if it didn't have an address where it wants to go.
So this is like a letter you're throwing in the mail, or I guess in the example of the Internet, the canonical example,
it's a postcard you're throwing in the mail.
And this postcard has a to address and it has a from address.
You already know that.
This is simple stuff.
Something else that it has is a port number.
.
Those of you who know the OSI model, this is layer 4.
This is the transport layer.
For example, these are port numbers you've heard about.
If you're talking to a web server, it's port 80 HTTP.
If you're talking to an FTP server, it's port 21.
Outbound email is SMTP port 25, etc.
You've heard these port numbers before.
These get sent along with every packet.
Again, this is a to address and a from address.
The from address is actually sort of a little more mysterious.
A lot of times when I'm teaching firewall classes, a lot of people are sort of uncertain or sort of surprised by this concept that every packet has a from port address.
And it turns out it's actually fairly valuable.
It's one of the things that keeps firewalls, by which a firewall can keep its internal state tables straight.
And we'll talk about that in a minute.
Also, inside an IP packet, there's lots of other stuff.
There's the data payload.
And this is your oversized ping of death packet or whatever it is you're sending today.
Error correction information, etc.
There's an awful lot of other stuff corresponding with other layers and flags, etc., etc.
But for purposes of the discussion of network address translation, the only things that are really important for us today are the to and from address for the to and from IP address and the to and from port address.
So we could talk about translating some of those addresses.
Is that for TCP IP or IP in general?
IP in general.
Okay, so now we're going to go to hide mode outbound, the first one.
Step number one.
Okay, this is hide mode.
You remember we have the LAN users who are sitting inside the LAN.
They're protected by hide mode.
They have a non-routable address.
They have one of these private addresses.
It's like 192.168, right?
So we know already that if they send a request out to some web server on the Internet,
using their own address,
where's the web server going to reply to, right?
If this packet goes out just by itself,
some web server somewhere on the Internet is going to get a request, an HTTP request,
from somebody who's identifying themselves as being 192.168.1.2.
That web server can't reply because we know that you can't respond to an address like that.
You can't send packets over the Internet to one of those non-routable addresses.
So we know already that some translation is going to have to occur.
Before that packet leaves your security perimeter.
So the packet leaves the client.
And you can see here,
I've just enumerated the four sort of different embedded addresses in that packet.
The first one is the IP source address is the private address.
You know, this is the private address of your web client there at work.
The IP destination, I'm just using www.website.com.
It's just a placeholder.
Your web client is going to pick a random high key.
It's going to have a TCP port number.
And the destination is going to be port 80.
And we know that because you're trying to talk to a web server.
As it leaves your firewall or your NAT box,
this is where the network address translation comes in.
Your NAT box overwrites the source address with the public IP address.
So you see there, the IP source, we've overwritten it with a virtual public address.
This is an address that you own.
You've been assigned it by your ISP,
and you own it, and it routes on the internet.
And the other three addresses you leave unchanged.
One of the important things here is that the firewall has to store information about this connection in the state table.
Because this packet, you know, this packet, this connection,
well, the firewall is actually sort of maintaining two different connections now.
One between the internal client and the firewall,
and another one between the firewall and this web server out on the internet.
And you have to keep all that straight.
Because when the answer comes back,
the firewall has to decide whether to let this in or not.
So the firewall keeps a state table.
Just a little bit of RAM,
just keeps a little piece of, just a simple little table that says,
okay, this inside user at this IP address,
he has an open connection going out to this web server.
His real address is this.
The fake external address we gave him is that.
And the connection is open.
He went out on this port number.
You know, just some basic information.
So the firewall keeps the state information.
In other words, in order to keep the channel open for the return traffic.
The remote public server, this is, you know, the website you're going to.
Now, he sees a request from a valid internet host.
You know, 205.219.84.5 or whatever.
That's a valid routable address.
So the web server sees this and says, hey, I'm a web server.
My job is to serve up web pages.
I've got a valid HTTP request here from a valid internet address.
So he just responds.
So he sends back.
Now, in a sense, it's easy to see he's just flipping the to and from
on both the IP address and the port address.
So he flips the two here.
So this packet that leaves the server has a source address from him,
which makes perfect sense.
He's sending it back to the virtual public address.
The port is on 80.
The port source is on 80.
And the destination is the original high TCP port number.
Now, this is sort of one of the mysteries that everyone is sort of surprised to see
is that when answers, when your replies come back from public web servers
or from any web server,
the two port number is the same random high TCP port number
that your machine selected at the beginning.
Now, since the firewall has kept that information in the table,
the firewall is able to disambiguate these replies
when they come back and decide who gets this packet.
Well, it...
Okay, the question is,
if you have multiple web browsers in hide mode in the same LAN,
and they all want to go out and browse the web simultaneously,
and they collide on high TCP port numbers,
how do you resolve that?
Well, the answer is we're much more willing to take the chance
they're going to collide on port numbers
than on the chance that they're going to collide on outbound IP addresses,
which we know they're going to collide
because they're all hiding behind the same IP address.
I don't know how the firewall resolves that.
It probably rejects the connection and says try again.
But there's 64,000 or 63,000 random high TCP port addresses,
so your chances of colliding are actually very small.
I would imagine if you were a firewall and somebody...
You know, the way you would keep those straight
would be either to reject the second connection
or maybe do something smart like keep track of,
well, this guy's going to a different IP address,
so when the answer comes back,
you match both the IP address and the port number,
and that's how you keep it straight.
So I imagine if you did both of those...
I mean, what are the chances of two LAN hosts
simultaneously going to Yahoo
both with the same random high port number?
Pretty small.
Excuse me?
Who would pick a different high port number?
The firewall.
The firewall.
All right, the question is,
is it possible the firewall would just pick a second high port number
going to the same destination?
Right.
There's something called port address translation.
The firewall does have the ability to play further games with this,
pick different port numbers, et cetera.
The chances of this happening are very small,
so it's not something we worry about a whole lot.
I don't know the details of how firewall one in particular resolves that.
But given the fact that there are 63,000
random high TCP port numbers,
and most LANs are hiding only a few hundred people
behind a single NAT configuration,
it doesn't seem to happen very often.
I'm sure there's a solution.
I'm sure they've worked on it,
but I haven't considered it very much.
Does the Mac address play a role in that at all?
Does the...
The Mac address?
Does the Mac address...
Does it get overwritten, right?
Well, Mac addresses are local to your Ethernet segment.
They don't cross routers.
They don't even cross switches.
So whatever Mac address you have on your local LAN client
could easily be long gone
by the time you get to your gateway router or your NAT box.
That's Layer 2 Ethernet only.
Doesn't have any part of this type of NAT.
Question?
All right.
The comment is,
if you're using firewall 1 in hide mode,
you're always going to be using port address translation.
It doesn't make sense, though,
if the port's maintaining the same port,
because it's really an older connection.
Okay.
So all they have to do is maintain
hide and port information, right?
Okay.
The comment is,
there's no reason to be maintaining force
the same port number.
Okay, fine.
This is not something I'm an expert on on these details.
I know that, you know,
the firewall handles them just fine,
and I haven't torn into it.
The response finally comes back to the client.
The client receives the reply from the Internet host.
So he's happy.
He sent out a request to an Internet server,
and he got his HTTP request back,
so he's perfectly happy.
Number nine, he has no idea NAT was used.
He has no idea that the web server
thought he was really talking to 204.205.199.1.
He has no idea.
And the server has no idea also.
The server, as far as he knows,
he received a valid request.
So one of the important issues here,
if NAT is working properly,
is that neither the client nor the server
have any idea that NAT was used,
and it doesn't matter.
They don't need to know,
except for some unusual circumstances such as the VPN.
Okay, that was outbound.
Now we're going to talk about hide mode
and inbound connections.
And if you're thinking ahead,
if you're reading ahead,
you might be thinking,
something's not right here.
Why should there be inbound connections and hide mode?
And it's true.
One of the purposes of hide mode
is that there can't be inbound connections.
So let's say that web server you just connected to
has an evil process on it,
and it tries to open another connection
back to your web client.
Those of you who have firewalls now
and watch the logs,
you see this all the time.
I'm running firewall one in my lab right now,
and I'm seeing it all the time.
I connect to some web server somewhere on the internet,
and three seconds later,
there's some, you know,
high TCP port attempted connection
right back to my web client.
My firewall drops them all and logs them,
but this happens all the time.
So in this scenario,
the packet comes in from this website.
Its destination is the public IP address,
the routable one that your NAT box was using.
Whatever the port source is and the port destination,
if it's an evil process, it can fake it all at once.
But it's coming in on something
that, well, clearly,
you're not allowing any port numbers to come through
because you're in hide mode on the LAN.
The firewall sees the incoming packet
and is unable to match it
with a known connection described in the state table.
So remember before,
we talked about the state table,
where the firewall keeps information
about connections that are outbound.
So when packets come back in,
it can look up in the table and say,
oh, yeah, I know about you.
I was expecting you.
You're the answer to this request
from someone in my LAN.
However, if a new connection takes place
and tries to come through,
the firewall looks at this and says,
what is this?
You're trying to connect
to somebody who's in hide mode.
And the firewall says,
you know, my job is to hide those hosts.
So the firewall says,
well, this is a virtual IP address only.
It's not a real IP address.
We just used it temporarily for hide mode NAT.
Also, here's an interesting question.
Even if the firewall could forward that packet
to some host inside the LAN,
it's an interesting question.
Which host is it intended for?
There's no way
there could be 200 hosts in there.
Lastly, hiding the internal hosts
is the whole point of hide mode.
So the next item here is,
well, the next thing that happens
is the connection fails.
No connection can be made,
hence hide mode.
All right, we've talked about
the first two in hide mode.
I'll more quickly go through static mode.
Okay, questions.
Question here?
.
Is there a cache that can be exploited
from the hide mode local addresses?
The only cache, so to speak,
would be, my understanding,
would be the state tables
that are stored in the firewall.
Well, sure, once the connection leaves the firewall,
you know, it's subject to all sorts of other,
you know, man-in-the-middle attacks or whatever,
and at that point,
it's just a standard connection
going out over the Internet.
I suppose if you were able to, you know,
hack into that, you could get back through.
But the firewall's fairly clever.
I don't know all the details
of what it's got there to prevent that,
but the firewall is only going to allow,
you know, replies from that IP address
with the correct port number
and within a certain period of time.
If you're hiding a couple of hundred LAN hosts
in hide mode,
hiding behind a single IP address
on the Internet,
and let's say you were sniffing that connection,
you sniffed somebody's T1 line going out to the Internet,
what do you see?
You see a single IP address that's incredibly chatty, right?
You see a single IP address
that's simultaneously talking to 53 websites.
That's hard. That's harder.
That's a real blizzard of information,
and it's harder to keep all those data streams separate
and tease them out and figure out who's what,
and it'd be hard work.
But, yeah, once the connection leaves the firewall
and goes out on the Internet insecurely,
yes, there's some things that can be done.
But the firewall is keeping a state table
with all the relevant information
and blocks everything that doesn't match
exactly what it's expecting.
The firewall is much smarter
than a simple access control list,
which just says,
let this, you know, port number into this IP address.
The firewall has a state table and says,
only this connection
and only for the next 30 seconds,
and you have to be this IP address,
you have to be this port number,
otherwise you get dropped.
Question?
.
Well, the only connection that stays open
is for return HTTP
information.
So it has to have a source port number of 80.
So there is no way...
The firewall, in order to allow web traffic requests
to come back to the client,
has to allow web traffic requests
to come back to the client.
So as long as they look like that,
yes, they're going to be let through.
But if they come in as an attempted telnet connection,
no, the port numbers are wrong.
It'll get blocked.
So, you know, the firewall is only smart enough
to let web traffic back.
But, you know, if there's something dangerous in that,
you know, you've attached a, you know,
a Trojan horse .exe to it,
well, the firewall has to do other things
to protect you against that.
But the connections that is opened
allows web traffic responses
back from that IP address
until the timeout.
.
.
.
All right, the question is that
if the web server responds
with the correct source IP address
and the correct source port address,
that matches the existing connection,
then the firewall will let that through.
The answer is yes.
I mean, that's what it does.
You know, the firewall has to do some other things
in terms of further inspection of attached files, say,
so much more high-level inspection,
layer seven in the packets.
But for what I'm talking about here
with network address translation,
it's just looking at layers three and four.
And so if something comes back through the firewall
that looks like valid web response,
it's something the web server sent,
then yes, it's going to let it back in.
This is just simply, you know,
allowing web access from the LAN.
Yes.
Gentleman in the back, white shirt.
.
.
.
.
All right, the question or the comment
is that there are some known
and perhaps patched issues involving firewalls
with buffer overflows.
Yeah, those are separate issues.
I'm not really trying to talk about some of the, you know,
the more detailed security issues here.
These are just...
I'm going through the basics of NAT.
Yes, there are other firewall issues.
.
Right, if you can do a buffer overflow in a firewall,
there's all sorts of things possible.
.
Okay, we're in static mode here outbound.
This is going out.
The firewall overwrites the IP source address
with the public IP address.
So this is just like we saw in hide mode.
This is the packet going outbound.
Since the from IP address on this packet
is a local non-routable address,
the firewall has to change it on the way outbound.
.
The question is, does the firewall accommodate
a single or perhaps multiple hide addresses?
My understanding with the Checkpoint Firewall 1 product,
it's only one IP address per, say, subnet
or per group or per rule.
My experience with the Cisco PIX firewall
is that you can designate a range of IP addresses
and it will randomly select among them.
That's even better.
Present your opponents with 100 IP addresses
and individual traffic is bouncing around between them,
sort of a spread spectrum sort of approach to it.
So it depends which product you have.
Firewall 1, I think, typically goes with 1,
but I know that Cisco PIX you can put a range in.
We're going to talk about it here in a minute,
but, of course, any IP address that you're hiding behind for NAT
has to be a public address that you own, right?
You can't just pick some random IP address
because then your traffic will go out,
but it won't come back.
The remote public server, it sees the request.
It looks perfectly reasonable.
It looks like a valid request.
It just flips the two addresses,
puts the payload in, and sends it back.
This is just a standard response from a web server.
Coming back in, the firewall has to do the translation again.
Since it was addressed to the virtual public IP address,
it now needs to be disambiguated
and sent back to the correct internal address.
So the moral of the story here is that
your network address translation box
changes one address on the way out
and one address on the way in, and that's it.
You just have to get the right one.
The DMZ server receives the reply from the Internet host.
The client has no idea that NAT was used,
and the server has no idea that NAT was used.
So, again, as long as you're using safe protocols
that don't embed an IP address inside the payload,
then this shouldn't be a problem.
Let's do the last one here before we take the break.
And, again, this is going to be for people
trying to connect to your web servers.
These are people on the Internet trying to connect
into your web server, your FTP server,
any of your public servers.
And, again, here's the four addresses.
It's being addressed to your virtual public address.
A leading question here, where does the Internet client
get this static virtual public address?
This is leading to the DNS discussion
we're going to have in the next hour.
If you have more than one IP address
assigned to a particular TCP IP host,
you have to be careful to make sure
that you load up your DNS servers with the correct address
depending on who's going to be querying that DNS server.
So if this is a public DNS server
that you want people on the Internet
to be able to get to your server with,
then you have to make sure that you're using
one of your virtual IP addresses for it, right?
You don't want to load up a public DNS server
with a 192.168. That won't do any good.
They'll never get to you.
So I want you to just keep in mind
that one of the issues you have to resolve
with network address translation
is how to load up your DNS servers.
On the way in, the firewall overwrites
the destination address with your private address.
Your DMZ server sees a request from an Internet host.
It replies.
The firewall on the way out,
this reply, the firewall has to overwrite
the source address one more time
so the packet appears to be coming
from a valid Internet address.
And lastly, the Internet client out there
receives the reply from the DMZ server.
The client has no idea that NAT was used.
The server has no idea that NAT was used.
So I just wanted to enumerate here
the four different types,
or the four different inbound and outbound
with both hide mode and static mode
and just sort of step through it.
It's not that complicated.
Once you sit down with paper and pencil
and work it through, it's not that tough.
You're only changing one address in each direction,
and all you're doing is just maintaining the consistency
that the packets have correct addresses,
whether they're on the inside or the outside.
The question is, how do you protect your LAN
from your compromised DMZ?
Well, you do it in your firewall
with rules in your firewall
and that you don't allow any connections
from hosts in the DMZ into hosts on the LAN.
So you plan ahead, and you say,
well, what if somebody totally owned my web server?
What's the first thing they're going to do?
They're going to try to use that as a stepping stone,
a springboard into the rest of your network.
And at that point, the firewall's going to stop them
as they're trying to connect from the inside.
So this is the main reason why you want to have
your DMZ and your LAN on separate LANs
and separate NIC cards, separate LAN segments,
so that the firewall has the best chance possible
of still providing a defense there.
Your DMZ is sort of a LAN
where things are partially trusted.
You'll let people from the outside in
to some degree to get on specific port numbers,
but if something on the DMZ starts trying to connect
back into your LAN, you don't allow it.
And so even if it's totally compromised, that's okay,
because you still have a firewall protecting
your inside LAN.
Yes?
The question is, that could be improved
with a cascading firewall?
Sure.
Question?
Is there a reason why some services
don't go through a firewall like voice?
Some of the new multimedia protocols are very complex.
They open up a control channel,
and then they send all sorts of port,
port number information about it,
about the connection,
and then they open up a whole bunch of random high TCP ports
in order to send the data.
Those of you who have worked with other access control lists,
et cetera, you know that FTP
is sort of a strange protocol, right?
It's a strange, not well-behaving protocol,
because once you do that port 21, port 20 thing,
you get it set up, and then all of a sudden
there's this discussion between the server and the client
about which random high TCP port number
are we going to use for the data channel.
Well, if you have a static access control list,
you can't prepare for that,
because if somebody's picking port, you know, 5021,
well, you can't, you know,
you can't set up an access control list
that you're constantly changing for that.
So FTP is special. FTP is different.
And that's why you need a firewall
that's smart enough to understand the protocol
and actually sniff the packets.
And this is what an FTP, you know,
this is how FTP is handled in a firewall,
is the firewall is actually sniffing the control channel
and saying, oh, you want port 5021 open?
Well, it temporarily makes a hole in the firewall
just for those IP addresses and just that port number
and only while the connection is valid.
So if you're running some of these,
sort of the new Microsoft multimedia H323
or whatever they are, I don't know all the details,
you need a firewall that understands them
and can sniff the control channel and say,
oh, okay, I need to open up these five high TCP ports.
It has to be a dynamic, intelligent thing.
You can't just, you know, set something
where we're going to allow this or we're not going to allow that.
It requires some real dynamic thinking going on
in order to make that work.
It's just about time, so I'm going to release you.
We're starting again at 4 o'clock on the dot
and ask me questions here in between.
Nat for newbies and not so newbies.
We're going to run until 4.50 p.m.
We have several more issues to discuss.
I'm going to talk about the benefits of using NAT.
I'm going to talk about some special firewall configuration issues.
I'm going to talk about DNS.
Questions at this point?
Those of you who were here before, any lingering questions?
Anything that we can talk about before we go forward?
.
All right, the question is,
even if you have NAT configured properly
and you have a lot of people on your LAN who are using hide mode,
the question is, what else can...
What else can you do to protect yourself from, what, your ISP
or somebody who is sniffing your T1 line, say,
and has figured out you're using NAT?
Well, if you think the intrusion is only local to you,
it's only between your gateway router and your ISP
or something like that,
go find another ISP somewhere who's willing to make...
No, who's willing to be the other end of a VPN
and just tunnel to them.
Find somebody, anybody on the Internet,
who's willing to be the other end of a VPN
and just tunnel all of your company's traffic through that box.
In other words, you'd be...
And a VPN, just to be really clear,
is an authenticated, encrypted, private channel
over the public Internet, over a public network.
So you could have your entire company VPN
through your public ISP over to somebody, anybody.
Pick somebody in Australia for 20 bucks a month.
It doesn't matter.
And then you get...
Then from there, you will emerge from the tunnel
and be released out on the Internet,
and your ISP or anybody who's sniffing your T1 line,
what do they see?
They see a ton of encrypted traffic,
and the value to them should be zero.
So if it's local to you like that,
then find another place to emerge on the Internet
or find another ISP or whatever.
That would be one way to do it.
Other questions?
Okay, I'm going to talk about the benefits of using NAT.
The reason I developed this talk was because
I think NAT is really cool.
I think you get an awful lot of benefits
for very little hassle.
I find it really valuable.
So there's basically four main issues here.
You can hide your internal network structure from outsiders,
structurally block all connections from the Internet
to your hosts using hide mode,
preserve scarce IP addresses,
and something called preventing leakage around your firewall,
which we'll talk about.
The first one here.
Since network address translation
provides the logical bridge between
your internal LAN IP addresses,
which you created,
and your external IP addresses,
which those are the ones you got from your ISP or IANA,
since you can completely control what happens inside
and you can completely control that logical bridging,
you can do whatever you want on the inside
and basically structure it so that
you can control what people on the outside see.
On the outside, you could have
five IP addresses in numeric sequence,
but they really represent servers
that are on five different DMZ subnets.
Whatever.
What matters is you can completely de-link
what people see on the outside
from what's actually happening on the inside.
We talk about tools like Nmap and port scanning, etc.
The whole point, if you're sort of a hacker
and you're doing your basic research on some company
and you were considering seeing
what sort of mischief you can get up to with them,
what's the first thing you're going to do?
You're going to try to scan their public IP addresses, right?
You're going to find out, well, what subnets do they have?
What do they own?
What domain names do they have registered?
These IP addresses, okay, let's do a port scan.
Okay, look, they've got a web server at these addresses.
They respond to FTP at these addresses.
Ooh, look, there's one of their mail servers, right?
This is easy stuff.
This is public information, basically.
But the nice thing is if you're using NAT,
then getting all of that public external information
gives you zero information about what's happening inside.
So this is the main benefit of NAT,
is you can make the outside look like whatever you want,
and it's completely orthogonal to what's happening on the inside.
There's absolutely no relation at all.
Question?
Okay, the question is, you've got a NAT box running,
which is also serving as an FTP server?
Well, okay, well, I guess I'd start off by saying that's a bad idea.
You should, you know, move your FTP server into the DMZ.
I mean, FTP is notorious, you know.
I mean, in my lab, my FTP server got ransacked two months ago through FTP.
So I'm here to tell you, I don't like FTP.
It's a bad thing to be serving.
So, no.
You don't want somebody to be able to do something evil with FTP
and then gain control of your NAT box.
Oh, man, you just gave them the keys.
So, first of all, separate those out.
Make your NAT box firewall just a NAT box firewall.
In fact, strip that thing down so there's nothing on it
except your NAT and your firewall.
So, here, I'll rephrase your question.
If you do have a FTP server inside
and you're making it available to outsiders using, say, static mode NAT,
yeah, people can tell that you've got,
you know, people do a port scan,
they will be able to tell, yeah, there's an FTP server there at that IP address.
That's what you want.
You're making it public.
I mean, that's why you have an FTP server.
So, yes, if you want people to be able to connect to your mail server,
web server, FTP server, then, yes, if they do a port scan,
they will see those ports open.
That's the point.
But you've limited it to exactly which IP addresses you want
and exactly which port numbers you want.
And you're not giving away any information.
You're not giving away any information about the inside structure.
All you're giving away is that somewhere in your organization
there's an FTP server, but who knows what that address is.
It's probably a private, non-routable inside address, right?
I mean, nobody, you know, you're not giving away anything.
You're giving away the fact that an FTP site exists at your company,
but you've already told people that.
So, that's not giving away anything more.
Other questions?
Okay, so this is the main benefit of NAT,
is you can completely decouple your internal structure
from your external structure, say, your external IP structure.
So, let ScriptKitties do all the port scanning they want.
All they're going to find out is that, yeah, your company has a web server.
Duh.
They're going to find out, yeah, your company has an FTP server.
You're a genius.
And you've got a mail server.
All right, you're still a genius.
Okay, that doesn't do them any good.
So, your public IP address structure is designed independently
of your internal structure.
Another benefit to NAT.
Posts protected by hide mode don't have a public IP address.
This is crucial.
In the previous hour, we talked about, in hide mode,
how someone can try to make a connection into one of the machines on your LAN.
Well, the machines on your LAN don't have a public IP address.
Okay, this is even better than an access control list.
This is even better than a router or a firewall saying,
oh, you know, we're not going to allow people to connect
to this particular IP address with this port number.
It's even better because this IP address doesn't even exist.
I mean, this is much better than an access control list.
This is, you've made an architectural change,
or it's being completely blocked by architecture.
They can't even tell that those machines exist.
Somebody on the outside could be pinging that machine all day long.
Well, first of all, what address would they ping?
Well, there is no address they could ping.
So you can't even get started.
So that's a real benefit.
A third benefit to network address translation
is to preserve scarce IPv4 IP addresses.
How many people here have heard of something called IPv6
coming along real soon now?
Okay, any year now.
I know we're working on it.
Back when the Internet, you know, was first starting,
you know, the concept of a 32-bit IP address,
that is such a vast IP address space,
nobody thought we'd ever run out.
Well, clearly, we're running out.
The same thing about 20-meg hard drives, right?
I mean, if a guy like me can have 16 IP addresses in his house,
you know, we're going to run out soon.
So there are only 128 Class A IP address blocks.
That's all there are.
There are only 32,000 Class Bs
and only about 8 million Class Cs.
We're running out.
I'll show you some examples here of people, you know,
sort of grabbing more than they needed.
There's some humorous examples here we'll get to.
But the fact is, there just aren't enough.
I mean, every organization who's bigger than five people
is going to claim they want their own Class B,
and there just aren't enough to go around.
Non-market allocation adds to scarcity.
Uh...
IP addresses, once they're assigned,
they tend to have fairly strong squatter's rights.
So once your company gets a Class B or a Class A,
you tend to hold on to it and resist people taking it from you.
And we'll see here some examples.
One of the reasons we tend to be running out of IP address blocks.
And also routing table restrictions.
The central core routers on the Internet
have to have routing table entries
for basically every single valid IP address in the world.
And my understanding...
I'm sure there's someone in this room who knows this better than I,
but my understanding, just a year or two ago,
I read an article saying, well, it's bigger than 64 megs now
and approaching 128, and it's really causing a problem,
because a lot of those routers only have 128 megs.
Well, first of all, imagine how difficult it is
for a router to dynamically search through
a 128-megabyte routing table to figure out
which, you know, which dick it should send this package to.
Or which packet out on.
So the more IP addresses you have out there
and the more fragmented they become,
the harder it is to keep straight where you route things.
Because a router on the central part of the Internet,
you know, has to be able to handle
pretty much every packet that comes its way.
Okay, let's talk about squatters' rights.
This is interesting stuff.
I was getting curious about
who owns all the Class A address blocks.
These are 1 through 127.
I guess 0 through 127.
Here's some of them.
40.
If you ever see a packet coming from 40,
you can thank Eli Lilly and Company.
Now, what are Eli Lilly and Company doing
with a full Class A address block?
I don't know.
That makes them equivalent to Sprint, I think,
in terms of how many IP addresses they have.
This is stupid.
Prudential Securities.
EI DuPont.
Merck.
Boeing.
I mean, Boeing, give me a break.
I mean, you know, with a Class B,
you could give an IP address to every seat
on every plane Boeing has ever sold, I think.
So, another one here,
which I think recently got yanked,
was Mercedes-Benz had 53.
You know, I like Mercedes-Benz,
but, you know, I'm pretty sure
that if I were allowed to use NAT,
I could hide any one of these companies
behind a Class C address block, right?
I mean, for any size company,
I mean, how many public IP addresses do you need?
Couple of web servers, couple of mail servers,
couple of FTP servers, right?
How many do you need?
10? 12?
And then maybe one hide address
for me to hide the rest of your people behind?
Or maybe a range?
But still, I'm willing to bet,
if you let me spend money on hardware like I want to,
I could hide any corporation in America
behind a single Class C IP address block.
You don't need, however, 16 million
or some ridiculous number of IP addresses.
So I'm looking here at number 48, Prudential Securities.
They got it in May of 1995.
Well, everyone talks about 1995
as the year the Internet really took off.
It looks like they just got it
in under the wire.
This was probably...
From my looking through IANA's website,
this is the last corporate Class A giveaway.
Some lucky guys there over at Prudential
pulling down a whole Class A for the company.
Now it would be a whole lot harder.
So, as you can see,
if these guys like Eli Lilly
can grab a whole Class A,
obviously we're not allocating IPv4 addresses
very efficiently,
and this is one of the reasons we're running out.
So, here, back to that.
So the reason you're able to use NAT
to preserve scarce IP addresses
is because all of your internal machines
have private non-routables,
and then the only ones that you need for the outside
are the static addresses that you're using
for people to come to your servers
and the hide mode addresses that you're using.
So almost any company could turn in their Class A
if they wanted to and pick up a Class C
and probably do just fine.
Another benefit of NAT, number four,
is preventing leakage around your firewall.
How many people here are sort of network administrators
or sysadmins or something like that,
or you're in charge of a network in some organization?
How many people have had somebody in your organization,
they get either a dial-up account at their desk
or they get a ricochet modem
or they get some other way to connect to the internet,
and before you know it,
they're starting to route internal LAN packets
through their private connection?
Has that happened to anybody here?
It's a real issue that somebody at work,
well, as we all know, the most dangerous thing in the world
is a helpful engineer with a screwdriver,
but let's say you get somebody at your office
who's sick and tired of not being able to get through the firewall
to do whatever he wants, so he gets a dial-up account,
and he gets a modem line in his office,
and he starts dialing out.
Well, let's say he's running Windows NT Server,
he accidentally checks the forward packets box,
and what do you know?
He's got a server connected to the internet without protection,
and now he's routing between the internet and your LAN,
and it's not going through your firewall.
Well, this is real trouble.
So one of the things that network address translation does for you
is it helps prevent this leakage.
I call this leakage.
If you're setting up a security perimeter
and you've got your firewall,
I mean, the whole point is that all of the traffic
has to go through that checkpoint, right?
If some of your traffic is leaking around your firewall
or your NAT box, well, that's not very secure
because you can be sure hackers are going to be leaking back,
well, taking it, yeah, okay,
leaking back in the other direction.
So this is not good.
So if you force all of your traffic,
well, if you use network address translation,
then you're forcing all of your traffic to go through the NAT box.
You can't leak around it because your addresses aren't any good.
So since the state tables on your NAT box
are private to your NAT box,
and since, therefore, nobody else can get in there
and sort of figure out what's going on,
if somebody does leak,
the private address they have is worthless on the outside.
So let's say somebody with a machine with a 192.168
dials up somewhere and connects to somebody and starts routing,
well, that 192.168 isn't going anywhere, right?
It's a private, non-routable address.
That's the point. It's worthless on the Internet.
Public addresses are worthless on the inside
because they have to go through the network address translation,
and traffic that leaks around the firewall
has senseless IP address translation.
So one of the nice things about NAT
is that you, not perfectly,
but fairly effectively ruin the effectiveness
of any traffic that tries to leak around your firewall.
This is Windows 98.
It's taking a little time here.
We're just going to go through the
Up here I have, I brought 50 copies,
which clearly isn't enough,
a printout of the presentation.
So if you want,
why don't you come up and grab one now.
Oh, yeah, by the end of the presentation,
I'll show you here.
This presentation is already posted on the Internet.
Okay, the fifth issue here.
Let's talk about just some basics,
how to configure a firewall for NAT.
Because NAT is usually done through a firewall.
You know, if someone's going to go through the trouble
of writing, designing, coding a firewall,
adding NAT is fairly easy.
So you should get them as a bundle.
I know that Checkpoint Firewall 1,
you get NAT with it for free, as they say.
And Cisco PIX has NAT also.
.
The question is,
what about the cheap personal hardware firewalls
like Linksys and D-Link?
They're great.
You know, hey, for 300 bucks,
geez, you can't go wrong.
It's not perfect.
You can't do all sorts of crazy configuration stuff.
You know, you can't get Microsoft
Net Meeting to go through it or something.
But, man, I strongly recommend everybody
have a personal firewall of some sort
if you're going to connect to the Internet.
And D-Link or Linksys,
these guys, you know, out of Taiwan
that make great stuff really inexpensive,
it works.
I've got a couple of them at home.
I'm sorry.
Like, what about Black Ice?
Black Ice didn't...
I think Steve Gibson's website,
I think he definitively proves it's worthless.
So go with something.
In his opinion, go with something else.
Zone Alarm is very good.
Yes.
.
To what?
.
.
Do hardware, firewalls,
and NAT boxes like the D-Link or the Linksys,
do they add much network overhead?
I think...
You're really asking do they add much latency?
No, under-debatable, milliseconds,
not a problem.
It's in hardware.
You know, it's an ASIC.
.
.
.
The announcement is that many of those boxes have NAT only and do not have firewall.
You're saying the Netgear in particular does have firewall?
Okay, the Netgear box includes some rules-based firewall technology from SonicWall.
One of the ones I use is a D-Link box that also provides my wireless, my 802.11b Wi-Fi connection.
It is a wireless node and NAT box and firewall with rules together for, I don't know, $230, something like that.
Whatever, the price is falling. You can't go wrong.
You know, get one that has firewall and NAT.
Other questions?
Okay.
Okay.
Okay.
The question is, am I going to address circumvention of NAT device?
No.
This is designed for newbies.
This is a tutorial so that the goal is that at the end of this you have more confidence and information about setting up NAT
rather than confidence and information about cracking it.
Is that the next hour?
That's the next hour.
We're meeting at a bar downtown.
So, I hate to be so simplistic here to say that, you know, in order to configure NAT on your firewall, the first step should be document your network, but it's, gosh, it's awfully important to do that.
If you don't know what you have, you don't know where you're going, and it's sometimes a lot of work to really figure out what you've got.
You know, I use what I call the pre-beta version of Visio.
Visio 0.1.
Visio 0.9, which is a piece of 8.5 by 11 paper and a pencil, and I draw and I make the diagram, and I draw in my, you know, I draw in all my subnets and everything, and it works just fine.
I've got to tell you, it's actually more complex than you think to really sit down and diagram what you've got.
You have to be really clear.
You have to know what are your IP subnets here.
You know, what are the default gateways?
What are the subnet masks?
You know, and you've got to learn all that technology.
You know, you have to learn all that terminology, you know, 255, 255, 255.
248, what does that mean?
You've got to figure that out.
So that's the first part, document your network.
Number two, make a plan.
Figure out where you want to be.
If you're going to be instituting NAT for the first time, there's actually some substantial changes you need to make to your network.
You're changing all of your internal IP addresses.
One of the technical things we've got to talk about here is ARP issues.
Just briefly, ARP is a Layer 3, Layer 2 protocol called Address Resolution Protocol.
This is how you convert Layer 3 addresses into Ethernet addresses.
Think of it as a vending machine.
You put in a Layer 3 address, and what you get out is a Layer 2 address.
If somebody's on your local area network and you want to talk to them through Ethernet, because that's how you talk to somebody on your LAN,
and you know their IP address but not their Ethernet address, you send out an ARP broadcast.
You say, yo, anybody out there on this IP address, and whoever has it answers back and gives you his Ethernet address.
Whatever.
We're going to talk about ARP here in a minute, but it's a technical detail you need to know.
It's sort of one of the few things we need to talk about down at Layer 2.
Also, we have to talk about routing issues, because if you're changing all of your IP addresses,
well, clearly you have to change all your routing setups.
Also, there's a special thing you have to worry about here.
Your firewall is a router first and has a bad attitude second, right?
That's what a firewall is.
It's a router first with an added bad attitude.
And when you're setting up your firewall, let's say if you're doing checkpoint firewall one,
and it sits on top of a Solaris box or an NT box, you want to get your NT box up and running first
and make sure you can route through it first before you add the firewall and start dropping packets.
So keep that in mind.
A firewall is just a router with some advanced, sophisticated access control lists and similar types of things.
So it's an interesting question.
If a packet is coming into your network and it needs to be NATed, say, static mode,
and while it's in that NAT box, its to address for IP gets changed, right?
It gets changed from the virtual public IP address into the private one.
Well, that brings up an interesting question about routing,
because where you route a packet is based entirely upon what is the to address of that packet.
So now you have a packet whose address, you know, its mailing address is changing,
so there's issues we have to go over here.
We have to talk about, you know, exactly how do you handle that.
How do you route a packet whose address is changing dynamically on you?
Do you route it to the public one? Do you route it to the private one?
Do you route first and NAT second? Do you NAT first? Whatever. We'll talk about that.
Oh, I'm locked up.
I should have used Linux. Thank you.
Oh, here we go.
I have this wireless LAN card here, so I'm probably being hacked.
We should expect messages coming up on the screen here any minute.
Can somebody return one of the printouts, please?
Thank you.
Thank you.
Well, unfortunately this machine...
Oh, here we go. We just got some action.
Okay, this is the next slide, so I'm going to try to continue on this.
If not, I can use the whiteboard.
In terms of documenting your network, as I said, this is really just the basics.
IP addresses, subnets, gateways, routers, firewalls, all connections through the security perimeter.
Again, I'm just talking about documenting.
What do you have, just so you know what you've got currently going?
I guess I'm going to continue to speak to the next slide while it slowly comes up here.
Making a plan.
The main issues are just what are your public and your private IP addresses.
Whatever your documentation is, your hand drawing, et cetera, you need to have it at least as detailed for what you're doing going forward.
And your NAT rules, you need to figure out in advance what are you going to do in terms of which machines are going to be in the LAN,
and are going to have hide mode network address translation, and which machines are going to be in your DMZ and have static mode.
Man, this is annoying.
I hate to reboot because it just takes forever on this machine.
I'm waiting for my mouse to come back.
Huh?
Yeah, that's next on my list.
The question is let's talk about DNS issues.
DNS issues are three slides away.
We've already been over at VPN.
In case you missed the first hour, there was a question about VPN, about VPN compatibility with network address translation.
It's the one sort of barely resolved issue.
VPN.
Okay, network address translation works best with, how do we describe them, well-behaved protocols that do not embed the IP address inside the payload of the packet.
Because VPN, excuse me, because network address translation, your NAT box is changing your IP address as these packets go in and out of your security perimeter.
So a well-behaved protocol, that doesn't matter.
They don't care.
They only look in the packet itself for the IP to and from destination and rely on that.
VPNs are special because they've added some security issues in there.
They've added some security protections and that they actually embed the IP address in the payload or encrypt it and embed it.
And so you can get some problems because on the other end of your VPN, it sees a packet coming from one IP address and yet the inside embedded information gives a different IP address.
So there are still issues with VPNs and network address translation.
The best solution is to use an integrated firewall that has both network address translation and VPN and that issue will be resolved by itself.
Yes.
What about hardware VPN?
What about hardware VPN?
Oh, I don't have a, I'm not able to really give a recommendation one way or the other.
There's a lot of different solutions.
IPSec has emerged as the standard.
So if someone is using IPSec, you should be fine.
Yes.
Talk about mail servers and key servers and what that would mean.
Go ahead.
What about SQL servers?
Is there anything you can say about that?
SQL servers or people's SQL servers are behind firewalls and you're employing that even though they can give them some support and can be used to see that people's servers are a big deal.
Is there anything you can say about those other boxes?
The question is I've talked about web servers, FTP servers, mail servers as being servers that you want available to people on the outside on the Internet and that you put them in the DMZ because of it.
And the question is does the same thing apply to SQL servers?
You have SQL servers outside the firewall that need to come to you guys to report.
You have SQL servers outside your firewall.
Then you can talk to SQL servers inside the firewall.
Well, ask the hackers who own that SQL server to do that for you.
I mean, whatever.
They need to talk to, you have SQL servers outside the firewall that need to.
By a PTP IP.
Talk back to some.
.
.
.
I guess I don't understand the configuration.
Why do you have SQL servers outside the firewall?
.
.
Well SQL uses, you know, as you mentioned the standard port numbers where you can configure that with your firewall or with your access control list and your router to allow or not allow that.
those port numbers. I think you can actually change those
port numbers, but if you
want to allow someone on the internet access
to your
whatever server, put it in your DMZ
and put the appropriate holes in the firewall. It's no
different. There's no difference between
SQL Server or Web Server. It's a little strange
to make that accessible to someone in the outside
world. It sounds a little risky, but there shouldn't
be any difference.
Excuse me?
Okay.
Question, yes.
Yes.
Okay, the question
involves some complicated interactions
between NAT and VPN. I guess in particular
using a cable modem at home and trying to use
VPN to get back into work.
Those interactions are a lot more
I love this.
Are a lot more complicated than
well, it looks like
we've got an hour now, don't we?
Yeah.
Here comes safe mode, I bet.
It's a complicated
interaction between
I'm so embarrassed.
It's a complicated
interaction between NAT and VPN.
I'm not prepared to
get into the details on it.
That's a lot tougher problem to solve.
You can control it.
But I'm saying that I figured it out that
right now, it would be a
program that hi4 would allow
to see a VPN account
but it's not that easy.
I get to the perspective
that VPN
is going to send it out
and that's really
wild for a 19-year-old
that we were going to need a hi4
after it was changed.
I don't want to send that off
to that app.
What kind of box were you, what kind of NAT box were you using?
OpenBSD.
OpenBSD, okay.
Okay.
Okay.
Other questions?
Yes.
Do ISPs use NATing?
It's a public, okay, the question is,
the question is, you went to a Steve Gibson's website, you tested the ShieldsUp thing,
and it reported back that you were on a private network, congratulations,
and this was news to you.
Are you on a public IP address?
It looks like a regular.
Is it possible that your ISP is doing some firewalling for you
and protecting some of those port numbers?
Yes.
Okay.
It might be the, well, you've got a public routable IP address,
and I've never heard of an ISP issuing non-routables to anybody.
So, I don't know.
Oh, you've got an ISP for dial-up who gives you non-routables?
Really?
Oh, sorry to hear that.
Other questions?
Yes.
So, I just assumed that all companies use NAT.
Am I wrong with that?
The question is, should I assume...
I've always assumed...
This sounds like a hacker question.
I've always assumed that companies would use NAT.
I'm surprised that...
I'm always hearing the impression that most companies don't use NAT.
All right, the question is, you've always assumed most companies use NAT,
and now, I guess I'm talking here sort of implying that not all companies use NAT,
and maybe they should get with the program.
I don't really know.
I think there's a lot of companies...
I mean, all the companies I've worked for,
I mean, everybody is desperately short of time and resources.
And if something...
If a company's been around for a long time and they've got public addresses
and it seems to work and, you know, they haven't been hacked severely recently,
there's no incentive for people to change that.
If you, you know, if you're Eli Lilly and company and you've got a Class A
and you want to preserve your squatters' rights, what are you going to do?
You're going to make as much use of those addresses as you can, right?
You're going to...
You know, you're not going to hide behind a single Class C
and then sit around and wait for someone to grab that Class A out of your hands, right?
You're going to make as much use of that as you can.
The coffee pot at Eli Lilly has its own...
IP address.
So, I don't know.
I don't really know how to really answer that question.
I suspect there's an awful lot of organizations out there
who, many years ago, got the network working once
and then dropped it and went on to other emergencies and haven't been back.
You know, that's...
You know how things get typically configured, right?
You get it working once and then it's not your most important five-alarm fire
and so you don't get back to it and, well, you know,
everyone's getting on the Internet and no one's complaining and, you know,
I got to do something else.
I don't have time.
So, I suspect there's lots of companies out there who have firewalls who aren't using that
and, yeah, I imagine so, but I don't have data on it.
Yes, question?
I don't think things go on like that.
It's that, you know, when you have them,
you have to switch with all your printers and pods and switches
and everything that has a real IP.
You know, we're all the same, right?
So, you know, everything's going to be down.
Or, you know, some of the things won't do that.
This is a good observation that converting IP addresses
or switching IP addresses at your organization is a real pain
and you're exactly right.
You sort of have to do it in one swell foop.
It's a lot of work.
It's a long, bad weekend and there's a lot of ways to go wrong on it.
I'll talk about that a little bit.
Yeah, if you're a company who's already got a few thousand users set up
with public IP addresses, who wants the headache of converting them over
to a public IP address?
Or to private?
I completely agree.
Yes?
I actually went through that situation myself with the governor of court.
There's about 3,000 people in the company and we switched IPs for whatever reason.
And it took three days to actually do all the IP changes and all the machines,
printers, everything.
And then I'm talking about those.
There's a myriad of different problems.
So, yeah.
Okay, so here's a war story up here about it took three days
to change the IP address.
It took three days to change IP addresses when you changed ISPs.
If you were using private IP addresses and you changed ISPs,
you only have to reconfigure your NAT box because none
of your internal addresses change, just your external ones.
You get a new class C from Bob's ISP, you're up and running in ten minutes, right?
It's not that tough.
Another real benefit of going with NAT.
Yes?
This leads to my question.
If you have a home network and you have a dynamically assigned public number,
but a small home network, how much trouble is that to maintain that side of the network?
Okay, the question is, what if you have a NAT box and on the outside,
the public IP address side of it, you're using a DHCP address,
an address that's dynamically given to you by your internet service provider.
Traditionally, typically, my, from what I've seen in NAT boxes,
you have to hard code in the external IP address.
But this is trouble if you've got, if you're getting it dynamically.
This is a problem.
The new boxes now allow for that.
I think my D-Link Wi-Fi hub, it's a combination of a switch, a firewall, a NAT box,
and a coffee maker, I think, and it's got, I think you can do DHCP on the outside.
So new hardware will allow that.
Checkpoint firewall one, I don't think so at this point.
So this, you know, there's a need for that, and it's easy to code it, so expect it soon.
Question?
More of an answer to the, excuse me,
if your network's set up properly, or you have subnets,
and so you can place your NAT box strategically throughout your company
and update the subnet at the time,
and you can look at the data.
The suggestion is a way that you can incrementally walk your company through a major IP address change.
And that is, if you've broken your network up into subnets,
you can do them one at a time, and use NAT boxes,
and have the outside of the NAT box still be in the old regime,
while the inside, or the downside, excuse me, the inside of the NAT box with the LAN,
that they're all going to be on the new addresses.
So if you're thinking cleverly through it, and you're willing to go through some of that, yeah,
you can sort of walk your way through one LAN at a time, and then maybe at the end,
there's a bad weekend where you have to sort of yank all those out, or do something else.
But yeah, you can incrementally work your way through.
It's still a headache.
There's still going to be problems, and Monday morning,
people are still going to be working through it.
They're going to be calling you, and they're going to be mad.
Yes, in the back.
Okay, another tip here, DHCP is particularly helpful.
Those of you who haven't discovered it yet, Dynamic Host Configuration Protocol,
it's a great way to propagate network changes
through your network, and your users don't even know.
I need to move on.
We've only got about seven or eight minutes left, so I'm going to try to make some more tracks here.
Windows 98 seems to be...
I spoke too soon.
There we go.
Okay, we talked about making a plan.
Back to Address Resolution Protocol, if you're going to be using, on the outside of your NAT box,
FACO IP addresses, you know, these are virtual public IP addresses, but for example,
this is really an issue, say, on a checkpoint firewall, on Solaris or on Windows NT.
If you're going to be using external public IP addresses that aren't native to that box,
you have to make sure that that box will respond properly.
to ARP broadcasts from your router.
If you have a gateway router who's trying to find this virtual IP address,
you have to ensure that the outside of your NAT box is going to respond to the ARP broadcasts
and announce itself properly as being the Ethernet host for that IP address.
A lot more complicated details in Firewall 1, you handle it in two different ways,
depending if you're on Solaris or if you're on Windows NT.
Just keep in mind, you have to get that straight.
On routing, as I mentioned, a firewall is a router.
It's a router first, and it's a firewall second.
Important question, how do you route a packet whose IP destination is changing?
Since routing is based upon what is your IP destination?
So the question sort of falls down to this, which comes first, the routing or the NATing?
And it depends on your firewall, you have to figure this out.
With Checkpoint, the routing comes first.
And the NATing is the very last thing that happens as the packet flies out the door.
So you have to route to the correct NIC address.
So you can route first, whether it's the LAN or the DMZ,
and then just as it's leaving, the very last step is the destination address gets changed.
So it can go either way.
You can route first or you can NAT first.
You just have to find out what it is in your firewall and make sure you understand that.
But keep in mind, you're trying to route a packet that has a dynamically changing destination address.
And as you can imagine, that can get tricky if you get it wrong.
DNS issues.
Here's the problem.
If you have two different IP addresses for a given host,
one on the inside and one on the outside,
which IP address should be returned with the DNS query?
Users on the inside, they need to get DNS resolved to the inside address.
Users on the outside need to get DNS resolved to the outside address.
So the question is, which answer should DNS resolve?
If you've got a, in your DMZ, you have www.company.com and you're inside on the LAN,
and you go to, you know, you say,
you set your browser to www.company.com, you resolve DNS.
Well, which address do you want to resolve to, the outside one or the inside one?
Here's the answer.
You have to have something called split DNS.
You need to maintain both an inside and an outside DNS server.
Insiders resolve to the inside.
Outsiders resolve to the outside.
And you limit the number of entries in the outside DNS server to just the minimum required.
So this is an additional enhanced security.
outside to use NS lookup and and just run through all the tables on your DNS
server and figure out all your internal machines right that wouldn't be good so
you list the five boxes that are in your DMZ you list their public IP addresses
and outsiders can see that but in terms of all the inside machines you use
inside DNS and and so that enhances your security by keeping the again you're
hiding the internal structure of your network from outsiders okay a summary
here NAT provides security at the network architecture level that's one of
the reasons I think it's so good it's below and before you get issues like
access control lists how many people here have screwed up an ACL and
accidentally let something through they shouldn't or accidentally block
something they shouldn't have I better see every hand go up if you've ever
touched a router people do it all the time it's much harder to screw up NAT
well once you get that working the first time then it's it's harder to get
it wrong later
it provides it provides security at a structural level the nice thing is all
the machines in your hide mode all the machines on your land they don't even
have public IP addresses so the question of whether somebody from the
outside could to you know can connect to it is sort of moot I've talked here
about the many benefits of NAT sort of a warning a caveat it may require some
significant restructuring of your network it's some real work to do IP
address changes in your company but I believe the benefits are pretty
darn nice if you can get a chance to pull it off where to get in more
information there's the internet engineering task force this is my
company information engine this presentation is already posted on the
site if you go to information engine comm you see a section called def con
9 and you can find my powerpoint presentation here I want to do some more
Q&A and this is about us it's sort of a one-man corporation I'm definitely
looking for more interesting opportunities I've heard a lot about the
resume is up here you know how to get to my website talk to me if you wish and
in the few minutes we have left actually about two minutes more questions and
I'll handle more questions when we're done here until we lose the room thank
you
